A modeling language uses specialized notation with specified semantics, such as diagrams or mathematical formulae, to define the behavior of a system. Such modeling languages can be used to specify and simulate the behavior of part or all of the logic in a software or hardware system. Examples of modeling languages include simple flowcharts and the vastly more complex Unified Modeling Language (UML), which is a general-purpose modeling language that has become an industry standard for specifying software-intensive systems. The UML has been standardized as ISO/IEC 19505:2012. OMG UML, ISO/IEC 19505 (2012).
Another common class of modeling languages are the dataflow languages, which describe the behavior of a system in terms of units (also called blocks, components, gates, etc.) and variables connecting them (also called networks, wires, connections, etc.). Two-dimensional graphical dataflow languages use notation similar to that used in circuit or logic diagrams to show the connections between units.
A common problem with tools for modeling and simulation is that large models are difficult to create initially as well as problematic to navigate once they have been created. It is also often difficult or inconvenient to find errors and issues, for example mismatching of variable names, type inconsistencies, incorrect assignment of constant values, or variables that are consumed without having been properly produced. Furthermore, it is inevitably necessary to update and modify a model over time; graphical modeling languages often make it difficult to analyze where changes occurred and the impact of those changes.
One common issue in particular with modeling languages is that it is often challenging to reuse logic in multiple situations. Reusing existing designs is desirable because it helps reduce development time and decreases the risk of errors. But for reuse to be effective, it must be possible to define a subsystem or group of logic only once no matter how many times it is reused, so that changes made in the single design propagate to all of the locations where it is used. Modeling languages often have limitations on the situations in which definitions can be reused, due to artificial constraints on data types, on atomicity (the ability to create loops in data flow), or on the appearance of a component (in visual modeling languages), which hinders the effectiveness of reuse.
Another issue in visual modeling languages is the overhead associated with manually laying out a diagram in 2D space. Often, the more complicated a model is, the more inconvenient this becomes. A particular issue in dataflow (circuit-style) languages is the need to manually position diagram input and output variables and specify information about their layout and direction of dataflow.
After a system has been modeled, the model can be simulated to ensure that it correctly implements the desired system behavior. One technique for verifying behavior of a system (or subsystem, or its constituent elements at any level of detail) utilizes a set of test vectors containing information such as initial conditions, timing, inputs, and expected outputs. Running the test vectors through any subsystem provides results indicative of the design and functional behavior of that subsystem.
When simulating a model of a system, in addition to testing with signal inputs that are expected during normal operation, abnormal inputs and internal states can be used instead. Testing under adverse input conditions such as these (sometimes referred to as “robustness testing”) can improve confidence in system integrity. An issue with many models in formal languages is that it is difficult to create these abnormal states, because the behavior of the model intentionally constrains the system to only be in normal states with valid intermediate computations based on the system's inputs.
Black box testing and white box testing lie at the two ends of the testing spectrum. A pure black box test of the entire system, (or subsystems with the results stitched together to represent the system), provides real world inputs and looks at its real-world outputs. A white box test, on the other hand, normally focuses on a specific component or system requirement where the tester controls the internal variables, instead of relying on the real-world variables, to prove functionality. Both types of testing are useful, but modeling tools do not always make it easy to choose the scope of simulation in a model as one appropriate for the type of testing being conducted.
When simulating large models, performance is essential to the usability of a modeling environment. Rapid interactivity significantly improves the ease of finding errors and developing test data. Excessive memory usage can harm simulation performance due to memory management overhead and poor cache locality, as well as impairing the ability to run many simulations simultaneously in parallel.